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Abstract 


The Presence Information Data Format (PIDF) defines a basic format 
for representing presence information for a presentity. This format 
defines a textual note, an indication of availability (open or 
closed) and a Uniform Resource Identifier (URI) for communication. 
The Rich Presence Information Data format (RPID) described here is an 
extension that adds optional elements to the Presence Information 
Data Format (PIDF). These extensions provide additional information 
about the presentity and its contacts. The information is designed 
so that much of it can be derived automatically, e.g., from calendar 
files or user activity. 


This extension includes information about what the person is doing, a 
grouping identifier for a tuple, when a service or device was last 
used, the type of place a person is in, what media communications 
might remain private, the relationship of a service tuple to another 
presentity, the person’s mood, the time zone it is located in, the 
type of service it offers, an icon reflecting the presentity’s 
status, and the overall role of the presentity. 


These extensions include presence information for persons, services 
(tuples), and devices. 
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1. Introduction 


The Presence Information Data Format (PIDF) definition [8] describes 
a basic presence information data format, encoded as an Extensible 
Markup Language (XML) [9] (SCHEMA-1 [10]) (SCHEMA-2 [11]), for 
exchanging presence information in systems compliant with the common 
model for presence and instant messaging [5]. It consists of a 
<presence> root element, zero or more <tuple> elements carrying 
presence information including a Uniform Resource Identifier (URI) 
for communication, zero or more <note> elements, and zero or more 
extension elements from other name spaces. Each tuple defines a 
basic status of either "open" or "closed". 
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However, it is frequently useful to convey additional information 
about a user that needs to be interpreted by an automata, and is 
therefore not appropriate to be placed in the <note> element of the 
PIDF document, which is typically intended for the human observer. 
Therefore, this specification defines extensions to the PIDF document 
format for conveying richer presence information. Generally, the 
extensions have been chosen to provide features common in existing 
presence systems at the time of writing, in addition to elements that 
could readily be derived automatically from existing sources of 
presence, such as calendaring systems or communication devices, or 
sources describing the user’s current physical environment. 


The presence data model [16] defines the concepts of service, device, 
and person as the data elements that are used to model the state of a 


presentity. (The term "presentity" is defined in RFC 2778 [5] and 
abbreviates presence entity. A presentity provides presence 
information to a presence service.) Services are encoded using the 


<tuple> element, defined in PIDF; devices and persons are represented 
by the <device> and <person> XML elements, respectively, defined in 
the data model [16]. However, neither PIDF nor the data model 
defines presence attributes beyond the <basic> status element. 


This specification defines additional presence attributes to describe 
person, service, and device data elements, summarized as "Rich 
Presence Information Data format for presence" (RPID). These 
attributes are specified by XML elements that extend the PIDF <tuple> 
element and the <device> and <person> elements defined in the data 
model. 


This extension has two main goals: 


1. Provide rich presence information that is at least as powerful as 
common commercial presence systems. Such feature-parity 
simplifies transition to systems complying with the Common 
Profile for Instant Messaging (CPIM) [14], both in terms of user 
acceptance and protocol conversion. 


2. Maintain backward-compatibility with PIDF, so that PIDF-only 
watchers and gateways can continue to function properly, 
naturally without access to the functionality described here. 


We make no assumptions as to how the information in the RPID elements 
is generated. Experience has shown that users are not always 
diligent about updating their presence status. Thus, we want to make 
it as easy as possible to derive RPID information from other 
information sources, such as personal calendars, the status of 
communication devices such as telephones, typing activity, and 
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physical presence detectors as commonly found in energy-management 
systems. 


Many of the elements correspond to data commonly found in personal 
calendars. Thus, we attempted to align some of the extensions with 
the usage found in calendar formats such as iCal [13]. 


The information in a presence document can be generated by a single 
entity or can be composed from information published by multiple 
entities. 


Note that PIDF documents and this extension can be used in two 
different contexts, namely, by the presentity to publish its presence 
status and by the presence server to notify some set of watchers. 

The presence server MAY compose, translate, or filter the published 
presence state before delivering customized presence information to 
the watcher. For example, it may merge presence information from 
multiple presence user agents, remove whole elements, translate 
values in elements, or remove information from elements. Mechanisms 
that filter calls and other communications to the presentity can 
subscribe to this presence information just like a regular watcher 
and in turn generate automated rules, such as scripts [15], that 
govern the actual communications behavior of the presentity. Details 
are described in the data model document. 


Since RPID is a PIDF XML document, it also uses the content type 
application/pidf+xml. 


Terminology and Conventions 

This memo makes use of the vocabulary defined in the IMPP model 
document [5]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE 
SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the memo are 
used in the same meaning as defined therein. 

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, 
RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted 
as described in BCP 14, REC 2119 [1]. 

RPID Elements 
1. Overview 


Some of the RPID elements describe services, some devices, and some 
the person. As such, they either extend <tuple>, <device>, or 
<person>, respectively. Below, we summarize the RPID elements. The 
next sections will then provide more detailed descriptions. 
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activities: The <activities> status element enumerates what the 
person is doing. 


class: An identifier that groups similar person elements, devices, 
or services. 


deviceID: A device identifier in a tuple references a <device> 
element, indicating that this device contributes to the service 
described by the tuple. 


mood: The <mood> status element indicates the mood of the person. 


place-is: The <place-is> status element reports on the properties of 
the place the presentity is currently at, such as the levels of 
light and noise. 


place-type: The <place-type> status elements reports the type of 
place the person is located in, such as 'classroom” or ‘home’. 


privacy: The <privacy> element distinguishes whether the 
communication service is likely to be observable by other parties. 


relationship: When a service is likely to reach a user besides the 
person associated with the presentity, the relationship indicates 
how that user relates to the person. 


service-class: The <service-class> element describes whether the 
service is delivered electronically, is a postal or delivery 
service, or describes in-person communications. 


sphere: The <sphere> element characterizes the overall current role 
of the presentity. 


status-icon: The <status-icon> element depicts the current status of 
the person or service. 


time-offset: The <time-offset> status element quantifies the time 
zone the person is in, expressed as the number of minutes away 
from UTC. 

user-input: The <user-input> element records the user-input or usage 


state of the service or device, based on human user input. 


The 'From/until?” column in Table 1 indicates by an ’x’ that the 
element can take ’from’ and “until” attributes. An ’x’ in the 
“Note?” column marks elements that can include a <note> element. The 
usage of these elements within the <person>, <tuple>, and <device> 
elements is shown in columns 4 through 6. An ’x’ in the respective 
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column indicates that the RPID element MAY appear as a child of that 
element. 


Lo HO A A A A 
Element | From/until | Note | <person> | <tuple> | <device> | 
? ? 

Lo A AO AA ME A. 
<activities> | x [i > dl x | | 

<class> | | x | x | x 
<deviceID> | x 

<mood> | x | x | x | | 

<place-is> | x | x] x | | 
<place-type> | x | x | x | | 

<privacy> | x | x | x | x | 
<relationship> | | x | | x | 
<service-class> x | x 

<sphere> | x | x 

<status-icon> | x | | x | x | 
<time-offset> ć | x | | x | | 
<user-input> | | | x | x | x | 
Lo HO A A A A 

Table 1 


In general, it is unlikely that a presentity will publish or announce 
all of these elements at the same time. Rather, these elements were 
chosen to give the presentity maximum flexibility in deriving this 
information from existing sources, such as calendaring tools, device 
activity sensors, or location trackers, as well as to manually 
configure this information. In either case, there is no guarantee 
that the information is accurate, as users forget to update calendars 
or may not always adjust the presence information manually. 


The namespace URIs for these elements defined by this specification 
are URNs [2], using the namespace identifier 'ietf” defined by [4] 
and extended by [6]: 


urn:ietf:params:xml:ns:pidf:rpid 


The elements marked with the value 'x” in column 2 of Table 1 MAY be 
qualified with the ’from’ and 'until” attributes to describe the 
absolute time when the element assumed this value and the absolute 
time until which this element is expected to be valid. Note that 
there can be multiple elements of the same type, whose time ranges 
SHOULD NOT overlap. 


Elements MAY contain an ’id’ attribute that allows to uniquely 
reference the element. 
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Enumerations can be extended by elements from other namespaces, as 
described in Section 6. The <activities>, <mood>, and <place-type> 
elements can also take <other> elements containing text, for custom 
free-text values specific to an application. 


All elements described in this document are optional within PIDF 
documents. 


3.2. Activities Element 


The <activities> element describes what the person is currently 
doing, expressed as an enumeration of activity-describing elements. 

A person can be engaged in multiple activities at the same time, 
e.g., traveling and having a meal. The <activities> element can be 
quite helpful to the watcher in judging how appropriate a 
communication attempt is and which means of communications is most 
likely to succeed and not annoy the person. The activity indications 
correspond roughly to the category field in calendar entries, such as 
Section 4.8.1.2 of RFC 2445 [13]. 


An activities enumeration consists of one or more elements using 
elements drawn from the list below, a string enclosed in the <other> 
element, or IANA-registered values from other namespaces (Section 7). 


If a person publishes an activity of "permanent-absence", it is 
likely that all services will report a status of CLOSED. In general, 
services MAY advertise either service status for any activity value. 


Activities such as <appointment>, <breakfast>, <dinner>, <holiday>, 
<lunch>, <meal>, <meeting>, <performance>, <travel>, or <vacation> 
can often be derived from calendar information. 


appointment: The person has a calendar appointment, without 
specifying exactly of what type. This activity is indicated if 
more detailed information is not available or the person chooses 
not to reveal more information. 


away: The person is physically away from all interactive 
communication devices. This activity element was included since 
it can often be derived automatically from security systems, 
energy management systems, or entry badge systems. Although this 
activity would typically be associated with a status of CLOSED 
across all services, a person may declare himself or herself away 
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to discourage communication, but indicate that he or she still can 
be reached if needed. However, communication attempts might reach 
an answering service, for example. 


breakfast: The person is eating the first meal of the day, usually 
eaten in the morning. 


busy: The person is busy, without further details. Although this 
activity would typically be associated with a status of CLOSED 
across all services, a person may declare himself or herself busy 
to discourage communication, but indicate that he or she still can 
be reached if needed. 


dinner: The person is having his or her main meal of the day, eaten 
in the evening or at midday. 


holiday: This is a scheduled national or local holiday. 


in-transit: The person is riding in a vehicle, such as a car, but 
not steering. The <place-type> element provides more specific 
information about the type of conveyance the person is using. 


looking-for-work: The presentity is looking for (paid) work. 
lunch: The person is eating his or her midday meal. 


meal: The person is scheduled for a meal, without specifying whether 
it is breakfast, lunch, or dinner, or some other meal. 


meeting: The person is in an assembly or gathering of people, as for 
a business, social, or religious purpose. A meeting is a sub- 
class of an appointment. 


on-the-phone: The person is talking on the telephone. This activity 
is included since it can often be derived automatically. 


other: The person is engaged in an activity with no defined 
representation as an <activities> element. The enclosed string 
describes the activity in plain text. 


performance: A performance is a sub-class of an appointment and 
includes musical, theatrical, and cinematic performances as well 
as lectures. It is distinguished from a meeting by the fact that 
the person may either be lecturing or be in the audience, with a 
potentially large number of other people, making interruptions 
particularly noticeable. 
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permanent-absence: The person will not return for the foreseeable 
future, e.g., because it is no longer working for the company. 
This activity is associated with a status of CLOSED across all 
services. 


playing: The person is occupying himself or herself in amusement, 
sport, or other recreation. 


presentation: The person is giving a presentation, lecture, or 
participating in a formal round-table discussion. 


shopping: The person is visiting stores in search of goods or 
services. 


sleeping: This activity category can often be generated 
automatically from a calendar, local time information, or 
biometric data. 


spectator: The person is observing an event, such as a sports event. 
steering: The person is controlling a vehicle, watercraft, or plane. 


travel: The person is on a business or personal trip, but not 
necessarily in-transit. 


tv: The person is watching television. 


unknown: The activity of the person is unknown. This element is 
generally not used together with other activities. 


vacation: A period of time devoted to pleasure, rest, or relaxation. 


working: The presentity is engaged in, typically paid, labor, as 
part of a profession or job. 


worship: The presentity is participating in religious rites. 


The <activities> element MAY be qualified with the ’from’ and ‘until’ 
attributes as described in Section 3.1. 


Example: 


<activities> 
<note>Enjoying the morning paper</note> 
<vacation/> 
<breakfast/> 
<other>reading</other> 
</activities> 
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3.3. Class Element 


The <class> element describes the class of the service, device, or 
person. Multiple elements can have the same class name within a 
presence document, but each person, service, or device can only have 
one class label. The naming of classes is left to the presentity. 
The presentity can use this information to group similar services, 
devices, or person elements or to convey information that the 
presence agent can use for filtering or authorization. This 
information is not generally presented to the watcher user interface. 


The <class> element MUST NOT be qualified with the ’from’ and ‘until’ 
attributes as described in Section 3.1. 


3.4. Device Identifier 


The <deviceID> element in the <tuple> element references the device 
that provides a particular service. The element is defined 
syntactically in the data model [16] schema. One service can be 
provided by multiple devices, so that each service tuple may contain 
zero or more <deviceID> elements. There is no significance in the 
order of these elements. 


The <deviceID> element MUST NOT be qualified with the ’from’ and 
‘until’ attributes as described in Section 3.1. 


3.5. Mood Element 


The <mood> element describes the mood of the presentity. The mood 
values are enumerated chosen by the presentity. The mood itself is 
provided as the element name of a defined child element of the <mood> 
element (e.g., <happy/>); one such child element is REQUIRED. The 
user MAY also specify a natural-language description of, or reason 
for, the mood in the <note> child of the <mood> element, which is 
OPTIONAL. (This definition follows the Jabber Extension JEP-107.) 

It is RECOMMENDED that an implementation support the mood values 
proposed in Jabber Extension JEP-0107, which in turn are a superset 
of the Wireless Village [18] mood values and the values enumerated in 
the Affective Knowledge Representation that has been defined by 
Lisetti [17]: 


A mood enumeration consists of one or more elements using elements 
drawn from the list below, a string enclosed in the <other> element, 


or IANA-registered values from other namespaces (Section 7). 


The <mood> element MAY be qualified with the 'from” and ‘until’ 
attributes as described in Section 3.1. 
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afraid 
amazed 
angry 
annoyed 
anxious 
ashamed 
bored 
brave 

calm 

cold 
confused 
contented 
cranky 
curious 
depressed 
disappointed 
disgusted 
distracted 
embarrassed 
excited 
flirtatious 
frustrated 
grumpy 
guilty 
happy 

hot 
humbled 
humiliated 
hungry 
hurt 
impressed 
in_awe 
in_love 
indignant 
interested 
invincible 
jealous 
lonely 
mean 

moody 
nervous 
neutral 
offended 
other 
playful 
proud 
relieved 
remorseful 
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restless 
sad 
sarcastic 
serious 
shocked 
shy 

sick 
sleepy 
stressed 
surprised 
thirsty 
unknown 
worried 


0000000000000 


Example: 


<mood> 
<note>I’m ready for the bar BOF!</note> 
<sleepy/> 
<thirsty/> 

</mood> 


3.6. Place-is Element 


The <place-is> element describes properties of the place the person 


is currently at. This offers the watcher an indication of what kind 
of communication is likely to be successful. Each major media type 
has its own set of attributes. Omitting the element indicates that 


the property is unknown. 
For audio, we define the following attributes: 


noisy: The person is in a place with a level of background noise 
that makes audio communications difficult. 


ok: The environmental conditions are suitable for audio 
communications. 


quiet: The person is in a place such as a library, restaurant, place 
of worship, or theater that discourages noise, conversation, and 
other distractions. 

unknown: The place attributes for audio are unknown. 


For video, we define the following attributes: 


toobright: The person is in a bright place, sufficient for good 
rendering on video. 
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ok: The environmental conditions are suitable for video. 


dark: The person is in a dark place, and thus the camera may not be 
able to capture a good image. 


unknown: The place attributes for video are unknown. 
For text (real-time text and instant messaging), we define 
uncomfortable: Typing or other text entry is uncomfortable. 


inappropriate: Typing or other text entry is inappropriate, e.g., 
since the user is in a vehicle or house of worship. 


ok: The environmental conditions are suitable for text-based 
communications. 


unknown: The place attributes for text are unknown. 


This list can be augmented by free-text values in a note or 
additional IANA-registered values (Section 7). 


The <place-is> element contains other elements, e.g., 


<place-is> 
<audio> 
<noisy /> 
</audio> 
<video> 
<dark /> 
</video> 
</place-is> 


The <place-is> element MAY be qualified with the ’from’ and ‘until’ 
attributes as described in Section 3.1. 


3.7. Place-type Element 
The <place-type> element describes the type of place the person is 
currently at. This offers the watcher an indication of what kind of 
communication is likely to be appropriate. The initial set of values 


is contained in RFC 4589 [12]. 


This list can be augmented by free-text values or additional IANA- 
registered values as described in RFC 4589. 
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8. 


The <place-type> element is a choice of elements, as in 


<place-type> 
<pt:street/> 
</place-type> 


The <place-type> element MAY be qualified with the ’from’ and ‘until’ 
attributes as described in Section 3.1. 


Privacy Element 


The <privacy> element indicates which types of communication third 
parties in the vicinity of the presentity are unlikely to be able to 
intercept accidentally or intentionally. This does not in any way 
describe the privacy properties of the electronic communication 
channel, e.g., properties of the encryption algorithm or the network 
protocol used. 


audio: Inappropriate individuals are not likely to overhear audio 


communications. 

text: Inappropriate individuals are not likely to see text 
communications. 

unknown: This information is unknown. 

video: Inappropriate individuals are not likely to see video 
communications. 


The <privacy> element can be used by logic executing on the 
watcher or by a composer to filter, sort and label tuples. For 
example, a composer may have rules that limit the publication of 
tuples labeled "private" to a select subset of the watchers. 


The <privacy> element MAY be qualified with the ’from’ and “until” 
attributes as described in Section 3.1. 


Example: 


<privacy> 
<text/> 
<audio/> 

</privacy> 
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3.9. Relationship Element 


The <relationship> element extends <tuple> and designates the type of 
relationship an alternate contact has with the presentity. This 
element is provided only if the tuple refers to somebody other than 
the presentity. Relationship values include "family", "friend", 
"associate" (e.g., for a colleague), "assistant", "supervisor", 
"self", and "unknown". The default is "self". 


If a relationship is indicated, the URI in the <contact> element 
refers to the entity, such as the assistant, that has a relationship 
to the presentity, not the presentity itself. 


Like tuples without a <relationship> qualifier, the <contact> element 
for tuples labeled with a relationship can contain either a 
communication URI such as "im", "sip", "sips", "h323", "tel", or 
"mailto", or a presence URI, such as "pres" or "sip". 


Example: 


<relationship> 
<friend/> 
</relationship> 


3.10. Service Class 


The <service-class> element extends <tuple> and designates the type 
of service offered. 


electronic: Delivery of information by electronic means, i.e., 
without delivering physical objects. Examples include telephone, 
fax, email, instant messaging, and SMS. 


postal: Delivery by the postal service, e.g., as a letter, parcel, 
or postcard. Delivery could be to a post office box or central 
mailroom rather than the presentity's office location, for 
example. 


courier: Delivery by messenger, overnight delivery, or courier. 
Courier-delivered messages are usually delivered to a receptionist 
rather than, say, a mailroom or receiving department. 


freight: Delivery by freight carrier, typically of larger objects 
that are not sent by postal mail or courier. The recipient is 
often the shipping department or a loading dock. 


in-person: Describes the coordinates for visits in person, as by a 
visitor, i.e., usually somebody’s office or residence. 
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unknown: The type of service is unknown. 


Electronic service is implied if omitted. The service types 
‘postal’, ‘courier’, 'freight', and ’in-person’ MUST NOT be used 
unless the contact URI is empty. Additional data elements defined 
elsewhere describe the physical service delivery address for the in- 
person, postal, or delivery services. Such addresses might be 
specified in geospatial coordinates, civic addresses, or some 
specialized address format, e.g., for interstellar addresses or a 
company-specific delivery system. 


Example: 
<service-class><postal/></service-class> 
3.11. Sphere Element 


The <sphere> element designates the current state and role that the 
person plays. For example, it might describe whether the person is 
in a work mode, at home, or participating in activities related to 
some other organization such as the IETF or a church. This document 
does not define names for these spheres except for two common ones, 
"work" and "home", as well as "unknown". 


Spheres allow the person to easily turn on or off certain rules that 
depend on what groups of people should be made aware of the person's 
status. For example, if the person is a Boy Scout leader, he might 
set the sphere to "scouting" and then have a rule set that allows 
other scout masters in his troop to see his presence status. As soon 
as he switches his status to "work", "home", or some other sphere, 
the fellow scouts would lose access. 


The <sphere> element MAY be qualified with the ’from’ and “until” 
attributes as described in Section 3.1. 


Example: 
<sphere> 
<home / > 
</sphere> 
3.12. Status-Icon Element 
The <status-icon> element includes a URI pointing to an image (icon) 
representing the current status of the person or service. The 


watcher MAY use this information to represent the status in a 
graphical user interface. Presentities SHOULD provide images of 
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sizes and aspect ratios that are appropriate for rendering as an 
icon. Support for JPEG, PNG, and GIF formats is RECOMMENDED. 
Watchers resolving the URI MUST validate whether the local copy of 
the icon is current when receiving a notification, using the standard 
cache control mechanism in the URI-identified retrieval protocol. 
Example: 


<status-icon>http://ww.example.com/playing.gif</status-icon> 


3.13. Time Offset 


The <time-offset> element describes the number of minutes of offset 
from UTC at the person's current location. A positive number 
indicates that the local time-of-day is ahead (i.e., east of) 
Universal Time, while a negative number indicates that the local 
time-of-day is behind (i.e., west of) Universal Time. Transitions 
into and out of daylight savings time may temporarily cause a 
difference between the true offset from UTC and the time offset 
element. 


An optional attribute, description, Can be used to describe the 
offset, e.g., by labeling the time zone. This description is meant 
for human consumption. 


Publishers on mobile devices SHOULD NOT publish this information 
unless they know the time offset information to reflect the current 
location. (For example, many laptop users do not update their time 
zone when traveling.) Publishers SHOULD update the information 
whenever they discover that their UTC offset has changed. 


Example: 


<time-offset description="America/New_York">-300 
</time-offset> 


3.14. User-Input Element 


The <user-input> element records the user-input or usage state of the 
service or device, based on human user input, e.g., keyboard, 
pointing device, or voice. If contained in a <person> element, it 
summarizes any user input activity across all services and devices 
operated by the presentity. The mechanism for such aggregation is 
beyond the scope of this document, but generally reflects the most 
recent user input across all devices and services. The element can 
assume one of two values, namely, 'active” or 'idle', with an 
optional 'last-input” attribute that records when the last user input 


Schulzrinne, et al. Standards Track [Page 17] 


RFC 4480 RIPD July 2006 


was received. An optional ’idle-threshold’ element records how long 
the presentity will wait before reporting the service or device to be 
idle, measured in seconds. 


(A two-state model was chosen since it would otherwise be necessary 
to send repeated last-input updates during continuous activity.) 


A service that wants to indicate user input activity sends a <user- 
input> 'active” indication when the user has provided user input 
within a configurable interval of time, the idle-threshold. If the 
user ceases to provide input and the idle-threshold has elapsed, the 
tuple is marked with a <user-input> ’idle’ indication instead, 
optionally including the time of last activity in the 'last-input” 
attribute. An example is below: 


<user-input idle-threshold="600" 
last-input="2004-10-21T13:20:00.000-05:00">idle</user-input> 


Depending on device or service capabilities, user input may be 
detected only for a particular application, i.e., when the 
application has user focus or when a user has sent a message or 
placed a call, or can be based on user input across all applications 
running on one end system. 


The <user-input> element may be used by a watcher, typically in 
combination with other data, to estimate how likely a user is to 
answer when contacting the service. A tuple that has not been used 
in a while may still be OPEN, but a watcher may choose to first 
contact a URI in a tuple that is both OPEN and has been used more 
recently. 


The <user-input> attribute can be omitted if the presentity wants to 
indicate that the device has not been used for a while, but does not 
want to reveal the precise duration, as in the following: 


<user-input>idle</user-input> 


Configuration MUST include the option to omit the ’last-input’ 
attribute. 


4. Example 


The example below describes the presentity 

‘pres: someone@example.com’, which has a SIP contact, 
‘'sip:someone@example.com’, representing a service. It also has a 
device contact, as an email box. The presentity is in a meeting, in 
a public office setting. The “until” information indicates that he 
will be there until 5:30 pm local time. The presentity also has an 
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assistant, sip:secretary@example.com, who happens to be available for 
communications. 


<?xml version="1.0" encoding="UTF-8"?> 
<presence xmlns="urn:ietf:params:xml:ns:pidf" 
xml1lns:dm="urn:ietf:params:xml:ns:pidf:data-model" 
xmlns:1t="urn:ietf:params:xml:ns:location-type" 
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" 
entity="pres:someone@example.com"> 


<tuple id="bs35r9"> 

<status> 
<basic>open</basic> 

</status> 
<dm:devicelID>urn: device: 0003ba4811e3</dm: deviceID> 
<rpid:relationship><rpid:self/></rpid:relationship> 
<rpid:service-class><rpid:electronic/></rpid:service-class> 
<contact priority="0.8">im:someone@mobile.example.net</contact> 
<note xml:lang="en">Don’t Disturb Please!</note> 
<note xml:lang="fr">Ne derangez pas, s’il vous plait</note> 
<timestamp>2005-10-27T16:49:29Z</timestamp> 

</tuple> 


<tuple id="ty4658"> 
<status> 
<basic>open</basic> 
</status> 
<rpid:relationship><rpid:assistant/></rpid:relationship> 
<contact priority="1.0">mailto:secretary@example.com</contact> 
</tuple> 


<tuple id="eg92n8"> 
<status> 
<basic>open</basic> 
</status> 
<dm:deviceID>urn:x-mac:0003ba4811e3</dm: deviceID> 
<rpid:class>email</rpid:class> 
<rpid:service-class><rpid:electronic/></rpid:service-class> 
<rpid:status-icon>http://example.com/mail.png</rpid:status-icon> 
<contact priority="1.0">mailto:someone@example.com</contact> 
</tuple> 


<note>1'11 be in Tokyo next week</note> 
<dm:device id="pcl47"> 
<rpid:user-input idle-threshold="600" 


last-input="2004-10-21T13:20:00-05:00">idle</rpid:user-input> 
<dm:deviceID>urn:device:0003ba4811e3</dm:deviceID> 
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<dm:note>PC</dm:note> 
</dm:device> 


<dm:person id="p1"> 

<rpid:activities from="2005-05-30T12:00:00+05:00" 

until="2005-05-30T17:00:00+05:00"> 

<rpid:note>Far away</rpid:note> 

<rpid:away/> 
</rpid:activities> 
<rpid:class>calendar</rpid:class> 
<rpid:mood> 

<rpid:angry/> 

<rpid:other>brooding</rpid:other> 
</rpid:mood> 
<rpid:place-is> 

<rpid:audio> 

<rpid:noisy/> 

</rpid:audio> 
</rpid:place-is> 
<rpid:place-type><lt:residence/></rpid:place-type> 
<rpid:privacy><rpid:unknown/></rpid:privacy> 
<rpid:sphere>bowling league</rpid:sphere> 
<rpid:status-icon>http://example.com/play.gif</rpid:status-icon> 


<rpid:time-offset>-240</rpid:time-offset> 
<dm:note>Scoring 120</dm:note> 
<dm:timestamp>2005-05-30T16:09:44+05:00</dm:timestamp> 
</dm:person> 
</presence> 


5. XML Schema Definitions 


The RPID schema is shown below. Due to limitations in composing 
schemas, not all XML documents that validate against the schema below 
are semantically valid RPID documents. In particular, the schema 
allows each element to appear anyhere in PIDF or data-model elements; 
Table 1 restricts where these elements can appear for semantically 
valid RPID documents. Elements that do not have from/until 
parameters MUST NOT appear more than once in each <person>, <tuple>, 
or <device>. 


5.1. urn:ietf:params:xml:ns:pidf:rpid 


<?xml version="1.0" encoding="UTF-8"?> 

<xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:rpid" 
xmlns="urn:ietf:params:xml:ns:pidf:rpid" 
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 


Schulzrinne, et al. Standards Track [Page 20] 


RFC 4480 RIPD July 2 


elementFormDefault="qualified" 
attributeFormDefault="unqualified"> 


<xs:simpleType name="activeldle"> 
<xs:restriction base="xs:string"> 
<xs:enumeration value="active"/> 
<xs:enumeration value="idle"/> 
</xs:restriction> 
</xs:simpleType> 


<xs:element name="activities"> 
<xs:annotation> 
<xs :documentation> 
Describes what the person is currently doing, expressed as 
an enumeration of activity-describing elements. A person 
Can be engaged in multiple activities at the same time, 
e.g., traveling and having a meal. 
</xs:documentation> 
</xs:annotation> 


<xs:complexType> 
<xs:sequence> 
<xs:element name="note" type="Note_t" minOccurs="0" 
maxOccurs="unbounded" /> 
<xs:choice> 
<xs:element name="unknown" type="empty" minOccurs="0"/> 
<xs:sequence maxOccurs="unbounded"> 
<xs:choice> 
<xs:element name="appointment" 
type="empty" /> 
<xs:element name="away" 
type="empty" /> 
<xs:element name="breakfast" 
type="empty" /> 
<xs:element name="busy" 
type="empty" /> 
<xs:element name="dinner" 
type="empty" /> 
<xs:element name="holiday" 
type="empty" /> 
<xs:element name="in-transit" 
type="empty" /> 
<xs:element name="looking-for-work" 
type="empty" /> 
<xs:element name="meal" 
type="empty" /> 
<xs:element name="meeting" 
type="empty" /> 
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<xs:element name="on-the-phone" 
type="empty" /> 
<xs:element name="performance" 
type="empty" /> 
<xs:element name="permanent-absence" 
type="empty" /> 
<xs:element name="playing" 
type="empty" /> 
<xs:element name="presentation" 
type="empty" /> 
<xs:element name="shopping" 
type="empty" /> 
<xs:element name="sleeping" 
type="empty" /> 
<xs:element name="spectator" 
type="empty" /> 
<xs:element name="steering" 
type="empty" /> 
<xs:element name="travel" 
type="empty" /> 
<xs:element name="tv" 
type="empty" /> 
<xs:element name="vacation" 
type="empty" /> 
<xs:element name="working" 
type="empty" /> 
<xs:element name="worship" 
type="empty" /> 
<xs:element name="other" 
type="Note_t" /> 
<xs:any namespace="##other" 
maxOccurs="unbounded" processContents="lax"/> 
</xs:choice> 
</xs:sequence> 
</xs:choice> 
</xs:sequence> 
<xs:attributeGroup ref="fromUntil"/> 
<xs:attribute name="id" type="xs:ID"/> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:complexType> 
</xs:element> 


<xs:element name="class" type="xs:token"> 
<xs:annotation> 
<xs:documentation> 
Describes the class of the service, device or person. 
</xs:documentation> 
</xs:annotation> 
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</xs:element> 


<xs:element name="mood"> 
<xs:annotation> 
<xs :documentation> 
Describes the mood of the presentity. 
</xs:documentation> 
</xs:annotation> 
<xs:complexType> 
<xs:sequence> 
<xs:element name="note" type="Note_t" minOccurs="0" 
maxOccurs="unbounded" /> 
<xs:choice> 
<xs:element name="unknown" type="empty"/> 
<xs:sequence maxOccurs="unbounded"> 
<xs:choice> 
<xs:element name="afraid" 
type="empty"/> 
<xs:element name="amazed" 
type="empty"/> 
<xs:element name="angry" 
type="empty"/> 
<xs:element name="annoyed" 
type="empty"/> 
<xs:element name="anxious" 
type="empty" /> 
<xs:element name="ashamed" 
type="empty" /> 
<xs:element name="bored" 
type="empty" /> 
<xs:element name="brave" 
type="empty" /> 
<xs:element name="calm" 
type="empty" /> 
<xs:element name="cold" 
type="empty" /> 
<xs:element name="confused" 
type="empty" /> 
<xs:element name="contented" 
type="empty" /> 
<xs:element name="cranky" 
type="empty" /> 
<xs:element name="curious" 
type="empty" /> 
<xs:element name="depressed" 
type="empty" /> 
<xs:element name="disappointed" 
type="empty" /> 


Schulzrinne, et al. Standards Track [Page 23] 


RFC 4480 RIPD July 2006 


<xs:element name="disgusted" 
type="empty" /> 

<xs:element name="distracted" 
type="empty" /> 

<xs:element name="embarrassed" 
type="empty" /> 

<xs:element name="excited" 
type="empty" /> 

<xs:element name="flirtatious" 
type="empty" /> 

<xs:element name="frustrated" 
type="empty" /> 

<xs:element name="grumpy" 
type="empty" /> 

<xs:element name="guilty" 
type="empty" /> 

<xs:element name="happy" 
type="empty" /> 

<xs:element name="hot" 
type="empty" /> 

<xs:element name="humbled" 
type="empty" /> 

<xs:element name="humiliated" 
type="empty" /> 

<xs:element name="hungry" 
type="empty" /> 

<xs:element name="hurt" 
type="empty" /> 

<xs:element name="impressed" 
type="empty" /> 

<xs:element name="in_awe" 
type="empty" /> 

<xs:element name="in_love" 
type="empty" /> 

<xs:element name="indignant" 
type="empty" /> 

<xs:element name="interested" 
type="empty" /> 

<xs:element name="invincible" 
type="empty" /> 

<xs:element name="jealous" 
type="empty" /> 

<xs:element name="lonely" 
type="empty" /> 

<xs:element name="mean" 
type="empty" /> 

<xs:element name="moody" 
type="empty" /> 
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<xs:element name="nervous" 
type="empty" /> 
<xs:element name="neutral" 
type="empty" /> 
<xs:element name="offended" 
type="empty" /> 
<xs:element name="playful" 
type="empty" /> 
<xs:element name="proud" 
type="empty" /> 
<xs:element name="relieved" 
type="empty" /> 
<xs:element name="remorseful" 
type="empty" /> 
<xs:element name="restless" 
type="empty" /> 
<xs:element name="sad" 
type="empty" /> 
<xs:element name="sarcastic" 
type="empty" /> 
<xs:element name="serious" 
type="empty" /> 
<xs:element name="shocked" 
type="empty" /> 
<xs:element name="shy" 
type="empty" /> 
<xs:element name="sick" 
type="empty" /> 
<xs:element name="sleepy" 
type="empty" /> 
<xs:element name="stressed" 
type="empty" /> 
<xs:element name="surprised" 
type="empty" /> 
<xs:element name="thirsty" 
type="empty" /> 
<xs:element name="worried" 
type="empty" /> 
<xs:element name="other" 
type="Note_t" /> 
<xs:any namespace="##other" 
maxOccurs="unbounded" processContents="lax"/> 
</xs:choice> 
</xs:sequence> 
</xs:choice> 
</xs:sequence> 
<xs:attributeGroup ref="fromUntil"/> 
<xs:attribute name="id" type="xs:ID"/> 
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<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:complexType> 
</xs:element> 


<xs:element name="place-is"> 
<xs:complexType> 
<xs:sequence> 
<xs:element name="note" type="Note_t" minOccurs="0" 
maxOccurs="unbounded" /> 
<xs:element name="audio" minOccurs="0"> 
<xs:complexType> 
<xs:choice> 


<xs:element name="noisy" type="empty" /> 
<xs:element name="ok" type="empty" /> 
<xs:element name="quiet" type="empty" /> 
<xs:element name="unknown" type="empty" /> 


</xs:choice> 
</xs:complexType> 
</xs:element> 
<xs:element name="video" 
<xs:complexType> 
<xs:choice> 


minOccurs="0"> 


<xs:element name="toobright" type="empty" /> 
<xs:element name="ok" type="empty" /> 
<xs:element name="dark" type="empty" /> 
<xs:element name="unknown" type="empty" /> 


</xs:choice> 
</xs:complexType> 
</xs:element> 
<xs:element name="text" 
<xs:complexType> 
<xs:choice> 
<xs:element 
<xs:element 
<xs:element 
<xs:element 
</xs:choice> 
</xs:complexType> 
</xs:element> 
</xs:sequence> 
<xs:attributeGroup ref="fromUntil"/> 
<xs:attribute name="id" type="xs:ID"/> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:complexType> 
</xs:element> 


minOccurs="0"> 


/> 
/> 


name="uncomfortable" type="empty" 
name="inappropriate" type="empty" 
name="ok" type="empty" /> 

name="unknown" type="empty" 


/> 


<xs:element name="place-type"> 
<xs:annotation> 
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<xs:documentation> 
Describes the type of place the person is currently at. 
</xs:documentation> 
</xs:annotation> 
<xs:complexType> 
<xs:sequence> 
<xs:element name="note" type="Note_t" minOccurs="0" 
maxOccurs="unbounded" /> 
<xs:choice> 
<xs:element name="other" type="Note_t"/> 
<xs:any namespace="##other" maxOccurs="unbounded" 
processContents="lax"/> 
</xs:choice> 
</xs:sequence> 
<xs:attributeGroup ref="fromUntil"/> 
<xs:attribute name="id" type="xs:ID"/> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:complexType> 
</xs:element> 


<xs:element name="privacy"> 
<xs:annotation> 
<xs:documentation> 
Indicates which type of communication third parties in t 
vicinity of the presentity are unlikely to be able to 
intercept accidentally or intentionally. 
</xs:documentation> 
</xs:annotation> 
<xs:complexType> 
<xs:sequence> 
<xs:element name="note" type="Note_t" minOccurs="0" 
maxOccurs="unbounded" /> 
<xs:choice> 
<xs:element name="unknown" type="empty"/> 
<xs:sequence minOccurs="1"> 
<xs:element name="audio" type="empty" minOccurs="0"/> 
<xs:element name="text" type="empty" minOccurs="0"/> 
<xs:element name="video" type="empty" minOccurs="0"/> 
<xs:any namespace="##other" minOccurs="0" 
maxOccurs="unbounded" processContents="lax"/> 
</xs:sequence> 
</xs:choice> 
</xs:sequence> 
<xs:attributeGroup ref="fromUntil"/> 
<xs:attribute name="id" type="xs:ID"/> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:complexType> 
</xs:element> 
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<xs:element name="relationship"> 
<xs:annotation> 
<xs:documentation> 
Designates the type of relationship an alternate contact 
has with the presentity. 
</xs:documentation> 
</xs:annotation> 
<xs:complexType> 
<xs:sequence> 
<xs:element name="note" type="Note_t" minOccurs="0" 
maxOccurs="unbounded" /> 
<xs:choice> 
<xs:element name="assistant" type="empty" /> 
<xs:element name="associate" type="empty" /> 
<xs:element name="family" type="empty" /> 
<xs:element name="friend" type="empty" /> 
<xs:element name="other" type="Note_t" minOccurs="0" /> 
<xs:element name="self" type="empty" /> 
<xs:element name="supervisor" type="empty" /> 
<xs:element name="unknown" type="empty" /> 
<xs:any namespace="##other" maxOccurs="unbounded" 
processContents="lax"/> 
</xs:choice> 
</xs:sequence> 
</xs:complexType> 
</xs:element> 


<xs:element name="service-class"> 
<xs:annotation> 
<xs:documentation> 
Designates the type of service offered. 
</xs:documentation> 
</xs:annotation> 
<xs:complexType> 
<xs:sequence> 
<xs:element name="note" type="Note_t" minOccurs="0" 
maxOccurs="unbounded" /> 
<xs:choice> 
<xs:element name="courier" type="empty" /> 
<xs:element name="electronic" type="empty" /> 
<xs:element name="freight" type="empty" /> 
<xs:element name="in-person" type="empty" /> 
<xs:element name="postal" type="empty" /> 
<xs:element name="unknown" type="empty" /> 
<xs:any namespace="##other" maxOccurs="unbounded" 
processContents="lax"/> 
</xs:choice> 
</xs:sequence> 
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</xs:complexType> 
</xs:element> 


<xs:element name="sphere"> 
<xs:annotation> 
<xs:documentation> 
Designates the current state and role that the person plays. 
</xs:documentation> 
</xs:annotation> 
<xs:complexType> 
<xs:choice minOccurs="0"> 
<xs:element name="home" type="empty" /> 
<xs:element name="work" type="empty" /> 
<xs:element name="unknown" type="empty" /> 
<xs:any namespace="##other" maxOccurs="unbounded" 
processContents="lax"/> 
</xs:choice> 
<xs:attributeGroup ref="fromUntil"/> 
<xs:attribute name="id" type="xs:ID"/> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:complexType> 
</xs:element> 


<xs:element name="status-icon"> 
<xs:annotation> 
<xs:documentation> 
A URI pointing to an image (icon) representing the current 
status of the person or service. 
</xs:documentation> 
</xs:annotation> 
<xs:complexType> 
<xs:simpleContent> 
<xs:extension base="xs:anyURI"> 
<xs:attributeGroup ref="fromUntil"/> 
<xs:attribute name="id" type="xs:ID"/> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:extension> 
</xs:simpleContent> 
</xs:complexType> 
</xs:element> 


<xs:element name="time-offset"> 
<xs:annotation> 
<xs:documentation> 
Describes the number of minutes of offset from UTC at the 
user’s current location. 
</xs:documentation> 
</xs:annotation> 


Schulzrinne, et al. Standards Track [Page 29] 


RFC 4480 RIPD July 2006 


<xs:complexType> 
<xs:simpleContent> 
<xs:extension base="xs:integer"> 
<xs:attributeGroup ref="fromUntil"/> 
<xs:attribute name="description" 
type="xs:string"/> 
<xs:attribute name="id" type="xs:ID"/> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:extension> 
</xs:simpleContent> 
</xs:complexType> 
</xs:element> 


<xs:element name="user-input"> 
<xs:annotation> 
<xs:documentation> 
Records the user-input or usage state of the service or 
device. 
</xs:documentation> 
</xs:annotation> 
<xs:complexType> 
<xs:simpleContent> 
<xs:extension base="activeldle"> 
<xs:attribute name="idle-threshold" 
type="xs:positivelnteger"/> 
<xs:attribute name="last-input" type="xs:dateTime"/> 
<xs:attribute name="id" type="xs:ID"/> 
<xs:anyAttribute namespace="##any" 
processContents="lax"/> 
</xs:extension> 
</xs:simpleContent> 
</xs:complexType> 
</xs:element> 
</xs:schema> 


6. Extending RPID 


Any developer can introduce their own element names, avoiding 
conflict by choosing an appropriate namespace URI. To add new 
standardized elements to the enumerations <activities>, <mood>, 
<privacy>, <relationship> and <service-class>, the extension process 
described in PIDF [9] is followed, i.e., such extensions would use 
namespace designators such as urn:ietf:params:xml:ns:pidf:ext, where 
‘ext’ is the name of the extension. Any new values for the <place- 
type> element are assigned according to [12] and are given a 
namespace designator at their time of registration. 
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To avoid the unnecessary proliferation of XML namespaces containing a 
single element, groups of element registrations for each of these 
enumerations, such as <privacy>, SHOULD be bundled into a single 
namespace rather than assigning a new namespace to each new element. 


7. IANA Considerations 


7.1. URN Sub-Namespace Registration for 
“urn:ietf:params:xml:ns:pidf:rpid” 


URI: urn:ietf:params:xml:ns:pidf:rpid 

Description: This is the XML namespace for XML elements defined by 
RFC 4480 to describe rich presence information extensions for the 
status element in the PIDF presence document format in the 
application/pidf+xml content type. 

Registrant Contact: IETF, SIMPLE working group, simple@ietf.org, 
Henning Schulzrinne, hgs@cs.columbia.edu 


XML: 


BEGIN 
<?xml version="1.0"?> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" 
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml 
<head> 
<meta http-equiv="content-type" 
content="text/html;charset=iso-8859-1"/> 
<title>RPID: Rich Presence Extensions to the Presence 
Information Data Format (PIDF)</title> 
</head> 
<body> 
<hl>Namespace for rich presence extension</h1> 
<h2>urn:ietf:params:xml:ns:pidf:rpid</h2> 
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4480.txt"> 
RFC&4480;</a>.</p> 
</body> 
</html> 
END 
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7.2. Schema Registration for Schema 
‘urn:ietf:params:xml:ns:pidf:status:rpid’ 


URI: urn:ietf:params:xml:ns:pidf:status:rpid 
Registrant Contact: IESG 
XML: See Section 5 


Note that this document does not need a new content type. It 
inherits the content type from [8], namely, application/pidf+xml. 


8. Internationalization Considerations 


RPID contains mostly tokens that are meant for consumption by 
programs, not directly by humans. Programs are expected to translate 
those tokens into language-appropriate text strings according to the 
preferences of the watcher. 


Some elements may contain <note> and <other> elements that can 
contain free text. These elements SHOULD be labeled with the ’xml: 
lang’ attribute to indicate their language and script. The 
specification allows multiple occurrences of these elements so that 
the presentity can convey <note> and <other> elements in multiple 
scripts and languages. If no ’xml:lang’ attribute is provided, the 
default value is "i-default" [3]. 


Since RPID is represented in XML, it provides native support for 
encoding information using the Unicode character set and its more 
compact representations including UTF-8. Conformant XML processors 
recognize both UTF-8 and UTF-16. Though XML includes provisions to 
identify and use other character encodings through use of an 
"encoding" attribute in an <?xml?> declaration, use of UTF-8 is 
RECOMMENDED in environments where parser encoding support 
incompatibility exists. 


A description of time-zone considerations can be found in 
Section 3.13. 


9. Security Considerations 


The security considerations in [8] apply, as well as [7]. Compared 
to PIDF, this presence document format reveals additional information 
about presentities that can be highly sensitive. Beyond traditional 
security measures to protect confidentiality and integrity, systems 
should offer a means to selectively reveal information to particular 
watchers and to inspect the information that is being published, 
particularly if it is generated automatically from other sources, 
such as calendars or sensors. 


Schulzrinne, et al. Standards Track [Page 32] 


RFC 4480 RIPD July 2006 


Like any reference to an external object, the <status-icon> may allow 
the presentity to induce the watcher to retrieve data from a third 
party (content indirection attack), thus either retrieving harmful 
content or adding to the server load of the referenced resource. 
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